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Abstract 


This document describes a backward-compatible technique that may be 

used by OSPF (Open Shortest Path First) implementations to advertise 
a router's unavailability to forward transit traffic or to lower the 
preference level for the paths through such a router. 


This document obsoletes RFC 3137. 


Status of This Memo 


Retana, 


This document is not an Internet Standards Track specification; it is 


published for informational purposes. 


This document is a product of the Internet Engineering Task Force 
(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 
approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 

Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6987. 
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1. Introduction 
In some situations, it may be advantageous to inform routers in a 
network not to use a specific router as a transit point but to still 
route to it. Possible situations include the following: 
o The router is in a critical condition (for example, has a very 
high CPU load or does not have enough memory to store all Link 


State Advertisements (LSAs) or build the routing table). 


o Graceful introduction and removal of the router to/from the 
network. 


o Other (administrative or traffic engineering) reasons. 
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Note that the solution introduced in this document does not remove 
the router from the topology view of the network (as could be done by 
just flushing that router's router-LSA) but discourages other routers 
from using it for transit routing, while still routing packets to the 
router's own IP addresses, i.e., the router is announced as a stub. 


It must be emphasized that the solution provides real benefits in 

networks designed with at least some level of redundancy, so that 

traffic can be routed around the stub router. Otherwise, traffic 

destined for the networks and reachable through such a stub router 
may still be routed through it. 


2. Solutions 


The solution introduced in this document solves two challenges 
associated with the outlined problem. In the description below, 
router X is the router announcing itself as a stub. The challenges 
are 


1) Making other routers prefer routes around router X while 
performing the Dijkstra calculation. 


2) Allowing other routers to reach IP prefixes directly connected to 
router X. 


Note that it would be easy to address issue 1) alone by just flushing 
router X's router-LSA from the domain. However, it does not solve 
problem 2), since other routers will not be able to use links to 
router X in Dijkstra (no back link), and because router X will not 
have links to its neighbors. 


To address both problems, router X announces its router-LSA to the 
neighbors with the cost of all non-stub links (links of the types 


other than 3) being set to MaxLinkMetric (defined in Section 3). 


The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 
[RFC5340]. 


2.1. OSPFv3-Only Solution 
OSPFv3 [RFC5340] introduces additional options to provide similar 
control of the forwarding topology; the R-bit provides an indication 


of whether a router is active and should be used for transit traffic. 


It is left to network operators to decide which technique to use in 
their network. See Section 4 for more details. 
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3. Maximum Link Metric 


Section 2 refers to the cost of all non-stub links as MaxLinkMetric, 
which is a new fixed architectural value introduced in this document. 


MaxLinkMetric 
The metric value indicating that a router-LSA link (see Section 2) 
should not be used for transit traffic. It is defined to be the 


16-bit binary value of all ones: Oxffff. 
4. Deployment Considerations 


When using MaxLinkMetric, some inconsistency may be seen if the 
network is constructed of routers that perform an intra-area Dijkstra 
calculation as specified in [RFC1247] (discarding link records in 
router-LSAs that have a MaxLinkMetric cost value) and routers that 
perform it as specified in [RFC1583] and higher (do not treat links 
with MaxLinkMetric cost as unreachable). Note that this 
inconsistency will not lead to routing loops, because if there are 
some alternate paths in the network, both types of routers will agree 
on using them rather than the path through the stub router. If the 
path through the stub router is the only one, the routers of the 
first type will not use the stub router for transit (which is the 
desired behavior), while the routers of the second type will still 
use this path. 


On the other hand, clearing the R-bit will consistently result in the 
router not being used for transit. 


The use of MaxLinkMetric or the R-bit in a network depends on the 
objectives of the operator. One of the possible considerations for 
selecting one or the other is in the desired behavior if the path 
through the stub router is the only one available. Using 
MaxLinkMetric allows for that path to be used while the R-bit 
doesn't. 


5. Security Considerations 


The technique described in this document does not introduce any new 
security issues into the OSPF protocol. 
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Appendix A. Changes from RFC 3137 
This document obsoletes [RFC3137]. 


In addition to editorial updates, this document defines a new 
architectural constant (MaxLinkMetric in Section 3) to eliminate any 
confusion about the interpretation of LSInfinity. It also 
incorporates and explains the use of the R-bit [RFC5340] as a 
solution to the problem addressed in the text. 
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